1. Field of the Invention
The present invention relates to the field of computer networks and more particularly to communication between clients and servers in the network.
2. Description of the Related Art
Many computer programs applications have been written to execute on computer platforms which include a processor and real time input/output (I/O) devices such as monitors for display of video and speakers for producing sound. The computer systems typically execute an application program interface (API) which interfaces with the application programs and a device driver which interfaces with the API and the I/O device.
The application programs are written to interface with a particular API. Rewriting the applications to interface with some other API would be time-consuming and expensive at best. More likely, significant commercial issues would be presented in attempting to get application program vendors to rewrite the applications to interface with new API's and, as a result, the may application programs would simply not be rewritten. A result could be that if a new computer architecture was introduced, the end user would have a very limited selection of application programs and this in turn would limit the market for the new computer architecture.
Application programs which require access to realtime I/O devices, especially networked applications, present unique problems especially when compared to non-realtime I/O such as display of graphics (which may be simply buffered and are not time dependent). Briefly, in the X architecture, a workstation 102 may be executing a client process 101 which performs real-time output where the real-time output is displayed on a server device (such as 104, 105, 106) coupled with the client process over a network
Prior art implementation for communication of information from a client to a server in an X architected implementation have generally provided for entirely new applications, or rewritten applications to interface with a special purpose API used for communicating over the network. An example of this is illustrated with reference to FIG. 3 which illustrates an application executing on a client and communicating through a network audio API over a network to an audio server. The network audio API is a special purpose API written to allow networked communication. Application programs executing on the client must be designed to interface with this special purpose API. This API may be referred to as a "network API".
The X Architecture and NCs
It is worthwhile to provide some background on the X architecture. The X Window System was developed originally at Massachusetts Institute of Technology (MIT) to fulfill a need for a distributed, hardware independent, user interface platform. The architecture of the X Window System is based on the client-server model. A single process, known as a server, is responsible for all input and output devices. The server creates and manipulates windows on a screen, produces text and graphics, and handles input and output devices such as a keyboard or mouse. The X server typically executes on a relatively low performance workstation or personal computer. An application program executes on another device referred to as the client.
FIG. 1 illustrates an X client process 101 executing on a workstation 102. The workstation 102 communicates over a network connection 103 with X servers executing on data terminal equipment (DTE) 104,105 and 106. The network connection 103 may support any of a number of network protocols including for example TCP/IP.
The distributed X architecture allows the server and clients to execute on separate machines located anywhere on the network.
More recently, the concept of network computers (NCs) has been introduced. NCs, in architectural concept, are essentially X servers. With the popularity of the internet, NC have come to be viewed as a relatively low cost computer which allows an easy software upgrade path as new generations of software become available. A new generation of software may be provided to allow the X client to offer additional services to the NC without need to go to the expense and trouble of installing new software on the NC.
Device Drivers
FIG. 2 illustrates aspects of a typical personal computer. The computer is executing an application program 201 (for example, the application may be a game program or other program requiring numerous input/output devices). The application program 201 interfaces with a local device high level application program interface (API) 202 such as the Windows.TM. media control interface (MCI). The local device API, in turn, interfaces with one or more device drivers 203. The device drivers 203 are typically supplied by the manufacturer of the device being controlled by the device driver 203. For example, in the illustration of FIG. 2, the device driver 203 controls audio card 204. Audio card 204 in turn controls audio input/output devices such as microphone 205 and speaker 206.
Certain types of data require presentation in time ordered, relatively equal intervals. Such data is sometimes termed isochronous data. Examples, include audio and graphics data. Typically, in the case of output data (e.g., driving the speaker) the card 204 will receive the data to be played and process it eventually resulting in sound being produced by the speaker 206. Just prior to the card 204 completing processing of any particular piece of data, the card 204 notifies the device driver and the device driver supplies more data.
As can be seen, the architecture described in connection with FIG. 2 assumes an operating system environment which expects local hardware, There is, in fact, a very large installed base of computer systems and application programs using the architecture described by FIG. 2.
It would be useful to allow NCs to use application programs written to execute in the computer architecture environment described in connection with FIG. 2. One approach has been to redesign at least the application program interface (API) software to provide commands to the remote device instead of to the local input/output card. This type of an API may be referred to as a "networked API" and this type of approach is discussed in greater detail in connection with FIG. 3.
The Network Audio System
One approach to supporting input/output devices in X environments is described in Fulton and Renda, The Network Audio System, Make Your Applications Sing (as well as dance)!, The X Resource, Issue IX, January, 1994, O'Reilly & Associates (the "NAS Reference). The NAS Reference describes a system developed by Network Computing Devices of Mountain View, Calif. (the assignee of the present application) for playing, recording and manipulating audio data over a network. The NAS Reference describes using the client/server model to split applications programs from specific hardware drivers. FIG. 3 illustrates the NAS architecture. This system is an example of a system in which a special purpose network API has been written, and the application programs must be written to interface with the network API.
Another system for managing input/output in a client/server environment is provided by the AudioFile, a device-independent network transport audio server described at http://www.tns.Ics.mit.edu/vs/audiofile.html.
Each of the prior art techniques for giving users access to real-time input/output devices over a network suffers from the need to rewrite applications to use new APIs designed specifically to access such devices over a network. This restriction precludes the use of existing industry standard applications.
Further, each of these solutions does not allow for efficiently measuring data flow in the system.
Thus, what is needed is an improved client/server communication system which gives users the ability to access real-time input/output devices over a network using existing industry standard application programs, such as Microsoft Windows applications, which are designed to access local real-time devices using existing standard application program interfaces, such as the standard Microsoft Windows API. It is further desirable for such an improved communication system to allow for the efficient measurement of data flow in the system.